refactor: ILPP workarounds for 2019.4 and 2020.2+ bugs #447
Conversation
…es and styling updates
…rk them as 'Obsolete' on Unity 2019.4
| using UnityEngine; | ||
|
|
||
| #if UNITY_2021_1_OR_NEWER | ||
| #warning Built-in Unity ILPP needs to be re-enabled after fixing self-referencing assembly reload issue on 2021.1+ and trunk |
There was a problem hiding this comment.
I'd like to highlight this and explain here a little further.
As @wackoisgod mentioned in the PR description, we want to re-enable Unity's built-in ILPP instead of this workaround:
The goal is that we can re-enable the unity version once self-references are fixed and other issues are resolved.
However, this workaround is still needed for 2019.4 target but 2020.x(LTS)+ will be OK without the workaround implementation and just work fine with Unity ILPP.
Also to overstate a little, we expect reloading self-referencing assemblies to be fixed on 2021.x+ and trunk in the future, hence this compiler warning on 2021.1+
| "dependencies": { | ||
| "com.unity.nuget.mono-cecil": "1.10.1-preview.1", | ||
| "com.unity.collections": "0.14.0-preview.16" | ||
| "com.unity.collections": "0.9.0-preview.6" |
There was a problem hiding this comment.
Downgrading due to Unity 2019.4 target
| [Browsable(false)] | ||
| [EditorBrowsable(EditorBrowsableState.Never)] | ||
| [DebuggerBrowsable(DebuggerBrowsableState.Never)] | ||
| #if UNITY_2020_2_OR_NEWER && !UNITY_2021_1_OR_NEWER | ||
| // RuntimeAccessModifiersILPP will make this `public` | ||
| internal static readonly Dictionary<uint, Action<NetworkedBehaviour, BitReader, ulong>> __ntable = new Dictionary<uint, Action<NetworkedBehaviour, BitReader, ulong>>(); | ||
| #else | ||
| [Obsolete("Please do not use, will no longer be exposed in the future versions (framework internal)")] | ||
| public static readonly Dictionary<uint, Action<NetworkedBehaviour, BitReader, ulong>> __ntable = new Dictionary<uint, Action<NetworkedBehaviour, BitReader, ulong>>(); | ||
| #endif |
There was a problem hiding this comment.
Hopefully, this "hide and warn" approach would be good enough for users on 2019.4 — they are expected to avoid interacting with these framework internal APIs!
IL Postprocessing has some issues in older versions of Unity where we had been running it in process VS 2020.2+ where we run it out of process which prevents some level of assembly conflicts but also has some different issues.
This PR does a couple of things, we hook into the
CompilationPipelineand listens for assemblies who have finished compiling and then does some checking and from there runs theILPostprocessoron the assembly as it had before what makes this work is that the assembly has already been compiled thus we don't run into some of the issues we had in the past.This API also keeps backwards compatibility with the Unity
ILPostprocessorAPI and can be disabled by setting theUSE_UNITY_ILPPscripting define and it will flip back over to using the internal Unity one thus making it easy to keep this for older versions of Unity but go back to the Unity version once issues are resolved.We also disable RuntimeAccessModifiersILPP which can be re-enabled with
MLAPI_RUNTIME_ILPPscripting define. At the moment its no longer needed.The goal is that we can re-enable the unity version once self-references are fixed and other issues are resolved.
Tested on 2019.4.18f1 and 2020.2.1f1
Should address (MTT-317/316)